home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / share / catman / u_man / cat1 / X11 / Xsecurity.z / Xsecurity
Text File  |  1998-10-20  |  16KB  |  331 lines
  1.  
  2.  
  3.  
  4.      XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))       XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666....3333))))        XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))
  5.  
  6.  
  7.  
  8.      NNNNAAAAMMMMEEEE
  9.           Xsecurity - X display access control
  10.  
  11.      SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.           X provides mechanism for implementing many access control
  13.           systems.  The sample implementation includes five
  14.           mechanisms:
  15.               Host Access                   Simple host-based access control.
  16.               MIT-MAGIC-COOKIE-1            Shared plain-text "cookies".
  17.               XDM-AUTHORIZATION-1           Secure DES based private-keys.
  18.               SUN-DES-1                     Based on Sun's secure rpc system.
  19.               MIT-KERBEROS-5                Kerberos Version 5 user-to-user.
  20.  
  21.      AAAACCCCCCCCEEEESSSSSSSS SSSSYYYYSSSSTTTTEEEEMMMM DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNNSSSS
  22.           Host Access
  23.                Any client on a host in the host access control list is
  24.                allowed access to the X server.  This system can work
  25.                reasonably well in an environment where everyone trusts
  26.                everyone, or when only a single person can log in to a
  27.                given machine, and is easy to use when the list of
  28.                hosts used is small.  This system does not work well
  29.                when multiple people can log in to a single machine and
  30.                mutual trust does not exist.  The list of allowed hosts
  31.                is stored in the X server and can be changed with the
  32.                _x_h_o_s_t command.  When using the more secure mechanisms
  33.                listed below, the host list is normally configured to
  34.                be the empty list, so that only authorized programs can
  35.                connect to the display.
  36.  
  37.           MIT-MAGIC-COOKIE-1
  38.                When using MIT-MAGIC-COOKIE-1, the client sends a 128
  39.                bit "cookie" along with the connection setup
  40.                information.  If the cookie presented by the client
  41.                matches one that the X server has, the connection is
  42.                allowed access.  The cookie is chosen so that it is
  43.                hard to guess; _x_d_m generates such cookies automatically
  44.                when this form of access control is used.  The user's
  45.                copy of the cookie is usually stored in the ._X_a_u_t_h_o_r_i_t_y
  46.                file in the home directory, although the environment
  47.                variable XXXXAAAAUUUUTTTTHHHHOOOORRRRIIIITTTTYYYY can be used to specify an alternate
  48.                location.  _X_d_m automatically passes a cookie to the
  49.                server for each new login session, and stores the
  50.                cookie in the user file at login.
  51.  
  52.                The cookie is transmitted on the network without
  53.                encryption, so there is nothing to prevent a network
  54.                snooper from obtaining the data and using it to gain
  55.                access to the X server.  This system is useful in an
  56.                environment where many users are running applications
  57.                on the same machine and want to avoid interference from
  58.                each other, with the caveat that this control is only
  59.                as good as the access control to the physical network.
  60.  
  61.  
  62.  
  63.      Page 1                                          (printed 4/30/98)
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.      XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))       XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666....3333))))        XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))
  71.  
  72.  
  73.  
  74.                In environments where network-level snooping is
  75.                difficult, this system can work reasonably well.
  76.  
  77.           XDM-AUTHORIZATION-1
  78.                Sites in the United States can use a DES-based access
  79.                control mechanism called XDM-AUTHORIZATION-1.  It is
  80.                similar in usage to MIT-MAGIC-COOKIE-1 in that a key is
  81.                stored in the ._X_a_u_t_h_o_r_i_t_y file and is shared with the X
  82.                server.  However, this key consists of two parts - a 56
  83.                bit DES encryption key and 64 bits of random data used
  84.                as the authenticator.
  85.  
  86.                When connecting to the X server, the application
  87.                generates 192 bits of data by combining the current
  88.                time in seconds (since 00:00 1/1/1970 GMT) along with
  89.                48 bits of "identifier".  For TCP/IP connections, the
  90.                identifier is the address plus port number; for local
  91.                connections it is the process ID and 32 bits to form a
  92.                unique id (in case multiple connections to the same
  93.                server are made from a single process).  This 192 bit
  94.                packet is then encrypted using the DES key and sent to
  95.                the X server, which is able to verify if the requestor
  96.                is authorized to connect by decrypting with the same
  97.                DES key and validating the authenticator and additional
  98.                data.  This system is useful in many environments where
  99.                host-based access control is inappropriate and where
  100.                network security cannot be ensured.
  101.  
  102.           SUN-DES-1
  103.                Recent versions of SunOS (and some other systems) have
  104.                included a secure public key remote procedure call
  105.                system.  This system is based on the notion of a
  106.                network principal; a user name and NIS domain pair.
  107.                Using this system, the X server can securely discover
  108.                the actual user name of the requesting process.  It
  109.                involves encrypting data with the X server's public
  110.                key, and so the identity of the user who started the X
  111.                server is needed for this; this identity is stored in
  112.                the ._X_a_u_t_h_o_r_i_t_y file.  By extending the semantics of
  113.                "host address" to include this notion of network
  114.                principal, this form of access control is very easy to
  115.                use.
  116.  
  117.                To allow access by a new user, use _x_h_o_s_t.  For example,
  118.                    xhost keith@ ruth@mit.edu
  119.                adds "keith" from the NIS domain of the local machine,
  120.                and "ruth" in the "mit.edu" NIS domain.  For keith or
  121.                ruth to successfully connect to the display, they must
  122.                add the principal who started the server to their
  123.                ._X_a_u_t_h_o_r_i_t_y file.  For example:
  124.                    xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
  125.                This system only works on machines which support Secure
  126.  
  127.  
  128.  
  129.      Page 2                                          (printed 4/30/98)
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))       XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666....3333))))        XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))
  137.  
  138.  
  139.  
  140.                RPC, and only for users which have set up the
  141.                appropriate public/private key pairs on their system.
  142.                See the Secure RPC documentation for details.  To
  143.                access the display from a remote host, you may have to
  144.                do a _k_e_y_l_o_g_i_n on the remote host first.
  145.  
  146.           MIT-KERBEROS-5
  147.                Kerberos is a network-based authentication scheme
  148.                developed by MIT for Project Athena.  It allows
  149.                mutually suspicious principals to authenticate each
  150.                other as long as each trusts a third party, Kerberos.
  151.                Each principal has a secret key known only to it and
  152.                Kerberos.  Principals includes servers, such as an FTP
  153.                server or X server, and human users, whose key is their
  154.                password.  Users gain access to services by getting
  155.                Kerberos tickets for those services from a Kerberos
  156.                server.  Since the X server has no place to store a
  157.                secret key, it shares keys with the user who logs in.
  158.                X authentication thus uses the user-to-user scheme of
  159.                Kerberos version 5.
  160.  
  161.                When you log in via _x_d_m, _x_d_m will use your password to
  162.                obtain the initial Kerberos tickets.  _x_d_m stores the
  163.                tickets in a credentials cache file and sets the
  164.                environment variable _K_R_B_5_C_C_N_A_M_E to point to the file.
  165.                The credentials cache is destroyed when the session
  166.                ends to reduce the chance of the tickets being stolen
  167.                before they expire.
  168.  
  169.                Since Kerberos is a user-based authorization protocol,
  170.                like the SUN-DES-1 protocol, the owner of a display can
  171.                enable and disable specific users, or Kerberos
  172.                principals.  The _x_h_o_s_t client is used to enable or
  173.                disable authorization.  For example,
  174.                    xhost krb5:judy krb5:gildea@x.org
  175.                adds "judy" from the Kerberos realm of the local
  176.                machine, and "gildea" from the "x.org" realm.
  177.  
  178.      TTTTHHHHEEEE AAAAUUUUTTTTHHHHOOOORRRRIIIIZZZZAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE
  179.           Except for Host Access control, each of these systems uses
  180.           data stored in the ._X_a_u_t_h_o_r_i_t_y file to generate the correct
  181.           authorization information to pass along to the X server at
  182.           connection setup.  MIT-MAGIC-COOKIE-1 and XDM-
  183.           AUTHORIZATION-1 store secret data in the file; so anyone who
  184.           can read the file can gain access to the X server.  SUN-
  185.           DES-1 stores only the identity of the principal who started
  186.           the server (unix._h_o_s_t_n_a_m_e@_d_o_m_a_i_n when the server is started
  187.           by _x_d_m), and so it is not useful to anyone not authorized to
  188.           connect to the server.
  189.  
  190.           Each entry in the ._X_a_u_t_h_o_r_i_t_y file matches a certain
  191.           connection family (TCP/IP, DECnet or local connections) and
  192.  
  193.  
  194.  
  195.      Page 3                                          (printed 4/30/98)
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.      XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))       XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666....3333))))        XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))
  203.  
  204.  
  205.  
  206.           X display name (hostname plus display number).  This allows
  207.           multiple authorization entries for different displays to
  208.           share the same data file.  A special connection family
  209.           (FamilyWild, value 65535) causes an entry to match every
  210.           display, allowing the entry to be used for all connections.
  211.           Each entry additionally contains the authorization name and
  212.           whatever private authorization data is needed by that
  213.           authorization type to generate the correct information at
  214.           connection setup time.
  215.  
  216.           The _x_a_u_t_h program manipulates the ._X_a_u_t_h_o_r_i_t_y file format.
  217.           It understands the semantics of the connection families and
  218.           address formats, displaying them in an easy to understand
  219.           format.  It also understands that SUN-DES-1 and MIT-
  220.           KERBEROS-5 use string values for the authorization data, and
  221.           displays them appropriately.
  222.  
  223.           The X server (when running on a workstation) reads
  224.           authorization information from a file name passed on the
  225.           command line with the -_a_u_t_h option (see the _X_s_e_r_v_e_r manual
  226.           page).  The authorization entries in the file are used to
  227.           control access to the server.  In each of the authorization
  228.           schemes listed above, the data needed by the server to
  229.           initialize an authorization scheme is identical to the data
  230.           needed by the client to generate the appropriate
  231.           authorization information, so the same file can be used by
  232.           both processes.  This is especially useful when _x_i_n_i_t is
  233.           used.
  234.  
  235.           MIT-MAGIC-COOKIE-1
  236.                This system uses 128 bits of data shared between the
  237.                user and the X server.  Any collection of bits can be
  238.                used.  _X_d_m generates these keys using a
  239.                cryptographically secure pseudo random number
  240.                generator, and so the key to the next session cannot be
  241.                computed from the current session key.
  242.  
  243.           XDM-AUTHORIZATION-1
  244.                This system uses two pieces of information.  First, 64
  245.                bits of random data, second a 56 bit DES encryption key
  246.                (again, random data) stored in 8 bytes, the last byte
  247.                of which is ignored.  _X_d_m generates these keys using
  248.                the same random number generator as is used for MIT-
  249.                MAGIC-COOKIE-1.
  250.  
  251.           SUN-DES-1
  252.                This system needs a string representation of the
  253.                principal which identifies the associated X server.
  254.                This information is used to encrypt the client's
  255.                authority information when it is sent to the X server.
  256.                When _x_d_m starts the X server, it uses the root
  257.                principal for the machine on which it is running
  258.  
  259.  
  260.  
  261.      Page 4                                          (printed 4/30/98)
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.      XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))       XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((RRRReeeelllleeeeaaaasssseeee 6666....3333))))        XXXXSSSSEEEECCCCUUUURRRRIIIITTTTYYYY((((1111))))
  269.  
  270.  
  271.  
  272.                (unix._h_o_s_t_n_a_m_e@_d_o_m_a_i_n, e.g.,
  273.                "unix.expire.lcs.mit.edu@our.domain.edu").  Putting the
  274.                correct principal name in the ._X_a_u_t_h_o_r_i_t_y file causes
  275.                Xlib to generate the appropriate authorization
  276.                information using the secure RPC library.
  277.  
  278.           MIT-KERBEROS-5
  279.                Kerberos reads tickets from the cache pointed to by the
  280.                _K_R_B_5_C_C_N_A_M_E environment variable, so does not use any
  281.                data from the ._X_a_u_t_h_o_r_i_t_y file.  An entry with no data
  282.                must still exist to tell clients that MIT-KERBEROS-5 is
  283.                available.
  284.  
  285.                Unlike the ._X_a_u_t_h_o_r_i_t_y file for clients, the authority
  286.                file passed by xdm to a local X server (with ``----aaaauuuutttthhhh
  287.                _f_i_l_e_n_a_m_e'', see xdm(1)) does contain the name of the
  288.                credentials cache, since the X server will not have the
  289.                _K_R_B_5_C_C_N_A_M_E environment variable set.  The data of the
  290.                MIT-KERBEROS-5 entry is the credentials cache name and
  291.                has the form ``UU:FILE:_f_i_l_e_n_a_m_e'', where _f_i_l_e_n_a_m_e is
  292.                the name of the credentials cache file created by xdm.
  293.                Note again that this form is _n_o_t used by clients.
  294.  
  295.      FFFFIIIILLLLEEEESSSS
  296.           .Xauthority
  297.  
  298.      SSSSEEEEEEEE AAAALLLLSSSSOOOO
  299.           X(1), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.      Page 5                                          (printed 4/30/98)
  328.  
  329.  
  330.  
  331.